home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group92c.txt
/
000079_icon-group-sender _Thu Nov 12 18:36:19 1992.msg
< prev
next >
Wrap
Internet Message Format
|
1993-01-04
|
2KB
Received: by cheltenham.cs.arizona.edu; Thu, 12 Nov 1992 19:43:36 MST
Date: Thu, 12 Nov 92 18:36:19 -0500
From: isidev!nowlin@uunet.uu.net
Message-Id: <9211122336.AA23580@relay2.UU.NET>
To: uunet!cs.arizona.edu!icon-group@uunet.UU.NET
Subject: Re rationale for sortf()
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
> The sortf() function in Icon V8.7 is defined as:
>
> sortf(X,i) Produces a sorted list of the elements of X. The
> results are similar to those of sort(X,i),
> except that among lists and among records,
> structure values are ordered by comparing their
> ith fields.
>
> Can someone explain to me why the second argument to the sortf() function is
> an integer index of the field in the record to sort on, instead of a string
> containing the field name?
The sortf() function works on lists in addition to records. It remains
flexible enough to do both by using an integer index. If you specified
field names with a string you would lose the ability to sort lists of
lists. I suppose you could overload the second argument so that integers
worked for both types of structures but a string in the context of a list
would generate a run-time error. Not worth it.
You can define tables with field names as key and the record index as value
and just use that in place of field name arguments to sortf(). When you
change record definitions you would have to change tables values. This
won't help with Idol unfortunately. Maybe Idol could put extra fields at
the end of records to avoid obscuring known index values?
Jerry Nowlin